DEFENSE  SYSTEMS  MANAGEMENT  COLLEGE 


JOINT  LOGISTICS  COMMANDERS  GUIDANCE  FOR  USE  OF 

EVOLUTIONARY  ACQUISITION 
STRATEGY 


mm:.  Fh 


MOPULAR  PBmi 


TRChtNQLOaF 


MAY  1995  ■ 

PUBLISHED  BY  THE 

DEFENSE  SYSTEMS  MANAGEMENT  COLLEGE  PRESS 
FORT  BELVOIR,VA  22060-5565 


REPORT  DOCUMEMTATI 


PAGE 


Form  Approved 
0MB  No.  0704-0188 


I "p  ' hiT  roi-  P'K  irr.liidtnq  iho  tor  reviewing  itHtruaiOO^  se.Kchmq  exi^itng  data  source, 

-  nh-r.n.^  and  thp  dota  needed,  and  eorr^pleung  and  rev-w-ng  the  •  olleaion  of  .nfcrmat>of^.  Vnd  ccnimenTs  rngord^ng  tins  burden  estimate  or  any  Other  aspeet  of  this 

I  crll^^cr.nn  of  mtonn.M!On;.ndud-ng  sugqesl.ons  bar  rectuemg  rhe.  oufdon  to  Wa^h.nqton  >  ieadquarfv^  Servn:es.  Cerectorafe  for  'nformatK^y^  Operations  and  Reports  1215  Jefferson 
J  r->u  -.t  Sii:iP  i:’n<i  Ari'nntnn  VA  22202-4102  and  to  th'^  Otfire  of  Manaqemf'nt  and  Rudoet  Paperwork  Reduction  Rro)ec.t  (0/04-0 18SK  A/ashrngton,  OC  20503. 


1  1.  AGENCY  USE  ONLY  (Leave  blank)  |  2.  REPORT  DATE  1  3.  RE.f^ORT  TYPE  ANi 

1  1  May  1995 . L _ .Manual. 

D  DATES  COVERED 

4.  TITLE  AND  SUBTITLE 

1  Joint  Logistics  Commanders  Guidance  for  Use  of 

Evolutionary  Acquisition  Strategy  To  Acquire  Weapon  System 

5.  FUNDING  NUMBERS 

3 

6.  AUTHOR(s)  Henry  Alberts  and  numerous  DSMC  faculty 

members,  representatives  from  the  Services  (Army,  Navy, 

AF,  MC  and  DLA).  Representatives  of  the  Office  of  the 
Secretary  of  Defense.  _  _ 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  AODRESS(ES) 

Defense  Systems  Management  College 

9820  Belvoir  Road 

Suite  G38 

Fort  Belvoir,  VA  22060-5565 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

AGENCY  REPORT  NUMBER 


9.  SPONSORINGTi^NfTORING  AGENCY  NAME(S)  AND  ADDRESS(ES)  10.  Si 

Defense  Systems  Management  College  * 

9820  Belvoir  Road  ”**” 

Suite  G38  |  1  |  ij  i? 

Fort  Belvoir,  VA  22060-5565 

I  e'>.  id(  i»<  ^  a  i  'j  V*; 


11.  SUPPLEMENTARY  NOTES 


12a.  DISTRIBUTION /AVAILABILITY  STATEMENT 


Approved  for  public  release;  distribution  unlimited 


13.  ABSTRACT  (Maximum  200  words) 

The  Joint  Logistics  Commands  offer  this  EA  process  as  a  tailored,  streamlined 
acquisition  strategy  for  acquiring  weapon  systems.  The  EA  process  is  consistent 
with  current  guidance  and  can  help  shorten  the  time  between  requirement  genesis^ 
and  systems  availability.  We  are  publishing  this  guide  to  encourage  consideration 
and  use  of  the  EA  strategy  for  future  v/eapon  systems  development  and  when  existing 
weapons  are  modified  to  improve  their  capabilities. 


quality  mSPECTED 


14.  SUBJECT  TERMS 

Policy  Statements  about  Evolutionary  Acquisition;  CharacteristicE 
vdiich  Indicate  Consideration  of  an  Alternative  Acquisition 
Strategy;  Adopting^an  Acq.  Strategy  vdiich  Accommodates  Change 


17.  SECURITY  CLASSIFICATION  18.  SECURITY  CLASSIFICATION  S  19.  SECURITY  CLASSIFICATION 

OF  REPORT  OF  THIS  PAGE  |  OF  ABSTRACT 


OF  REPORT 

Unclassified 


NSN  75A0-01 -280-5500 


Unclassified 


OF  ABSTRACT 

Unclassified 


15.  NUMBER  OF  PAGES 


16.  PRICE  CODE 


20.  LIMITATION  OF  ABSTRACT 


Unlimited 


Standard  Form  298  (Rev  2-89) 

ProsenbeeJ  by  ANSI  Std  Z39-18 
29B- 102 


JOINT  LOGISTICS  COMMANDERS  GUIDANCE 

FOR  USE  OF 

EVOLUTIONARY  ACQUISITION 

STRATEGY 

TO  ACQUIRE  WEAPON  SYSTEMS 


MAY  1995 


PUBLISHED  BY  THE 

DEFENSE  SYSTEMS  MANAGEMENT  COLLEGE  PRESS 
FORT  BELVOIR,  VA  22060-5565 


19950110  011 


TABLE  OF  CONTENTS 


Foreword . v 

Preface . vi 

Chapter  1  —  Policy  Statements  About  Evolutionary  Acquisition 

Background . 1-1 

Chapter  2  —  An  Overview  of  Evolutionary  Acquisition 

Background  Studies . 2-1 

Evolutionary  Acquisition  Defined . 2-2 

Successful  Evolutionary  Acquisition . 2-3 

Chapter  3  —  Characteristics  Which  Indicate  Consideration  of  An  Alternative 
Acquisition  Strategy 

Background . 3-1 

Requirements . 3-1 

Technology . 3-1 

User  Involvement . 3-1 

Schedule . 3-2 

Funding . 3-2 

Other  Constraints . 3-2 

Uncertainty . 3-2 

Lack  of  Knowledge . 3-2 

Omens  of  Change . 3-3 

Review  of  Weapon  Systems  Characteristics . 3-3 

Chapter  4  —  Adopting  an  Acquisition  Strategy  Which  Accommodates  Change 

Activities  and  Actions  Required  to  Implement  Evolutionary 

Acquisition  Approaches . 4-1 

Relationships  Among  the  Acquisition  Executive,  User  and  User 

Surrogate,  Developer,  and  Tester . 4-2 

Changes  to  Current  Management  Procedures 

and  Documents . 4-4 

Tailoring  the  Acquisition  Approach . 4-8 

Tailoring  Guidelines . 4-8 

Chapter  5  —  Guidelines  for  Preparing  the  Acquisition  Strategy  Report 
for  an  Evolutionary  Acquisition 

Background . 5-1 

iii 


Evolutionary  Acquisition  Summary . 5-7 

Sources  of  Additional  Information . 5-7 

List  of  Figures 

Figure  2.1  Evolutionary  Acquisition  Overview . 2-4 

Figure  4.1  Tailoring  the  Acquisition  Approach . 4-9 

Figure  5 . 1  Evolutionary  Acquisition . 5-8 

Appendix  A . A-1 


iv 


FOREWORD 


SUBJECT:  Evolutionary  Acquisition  Guide 

1.  This  Evolutionary  Acquisition  Guide  was  commissioned  by  the  Joint  Logistics  Conxmanders 
and  developed  vmder  the  auspices  of  the  Joint  Group  on  Acquisition  Initiatives  (JG-AI).  The  Project 
team  which  created  the  guide  was  led  by  the  Defense  Systems  Management  College  (DSMC)  and 
included  representatives  from  the  Services  and  Defense  Logistics  Agency  (DLA).  This  guide  is 
one  example  of  DoD  streamlining  and  improvement  in  the  quality  of  our  acquisition  policies  and 
processes. 

2.  We  believe  this  Evolutionary  Acquisition  Guide  will  provide  Program  Managers  with  a  good 
alternative  means  to  develop  and  acquire  weapon  systems  while  providing  for  incremental  growth 
in  capability  overtime.  This  guide  is  not  and  should  not  be  interpreted  as  a  policy  mandate/  but  as 
a  proven  technique  that  may  be  considered.  Use  of  the  techniques  recommended  in  the  guide  may 
be  tailored  as  needed  for  each  program. 


3.  The  JLC  recommends  use  of  this  Guide  as  a  foundation  for  effective  weapon  system  acquisition 
planning.  If  you  require  additional  information  on  this  guide,  please  contact  Mr.  Henry  Alberts, 
Chairperson,  DSMC  Evolutionary  Acquisition  Team  at  (703)  805-3464  or  DSN  655-3464. 
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lieutenant  General,  USMC 
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RONALD  W.  YATES 
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Air  Force  Materiel  Command 


EDWARD  M.  STRAW 
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Director,  Defense  Logistics  Agency 
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PREFACE 


The  environment  in  which  military  acquisition  occurs  has  changed  since  the  Joint  Logis¬ 
tics  Commanders  (JLC)  Guidance  on  Evolutionary  Acquisition  (EA)  was  first  issued.  In¬ 
deed,  the  changes  are  so  sweeping  that  it  appears  necessary  to  re-think  completely  the 
methodology  used  to  acquire  almost  all  kinds  of  weapon  systems. 

The  most  obvious  characteristic  of  the  changed  acquisition  environment  is  the  absence  of 
a  long-term,  consistent  singular  threat;  a  circumstance  which  must  affect  the  stability  of 
military  requirements. 

Another  change  involves  the  expansion  of  the  civil  marketplace  and  the  effect  of  that 
expansion  on  the  pace  and  condition  of  technology  development.  Once,  military  needs 
tended  to  drive  technology  forward.  Increasingly,  technology  has  become  responsive  to 
civilian  world  market  forces.  In  the  most  rapidly  advancing  technology  areas  of  electronic, 
computational  and  information  system  development.  United  States  (U.S.)  military  activ¬ 
ity  provides  only  a  marginal  revenue  base  for  the  U.S.  industrial  base. 

Prior  experience  with  Command,  Control,  Communication  and  Intelligence  system  ac¬ 
quisition  has  shown  that  use  of  conventional  acquisition  strategies  has  often  led  to  imsat- 
isfactory  results.  The  reasons  have  been  defined  by  many  studies.  But  the  principal  diffi¬ 
culty  with  traditional  acquisition  activities  has  been  that  the  time  required  to  complete  the 
entire  process  has  lagged  well  behind  changes  in  requirements  and  in  capabilities  pro¬ 
vided  by  technology  advances.  Environmental  changes  within  which  acquisition  takes 
place  may  have  exacerbated  previous  difficulties  in  maintaining  currency,  both  in  military 
capability  available  and  in  technology  used  to  provide  it. 

Even  as  this  guide  has  been  prepared,  a  complete  review  of  acquisition  policy  has  been 
imdertaken  by  the  Secretary  and  Deputy  Secretary  of  Defense,  and  the  office  of  the  Deputy 
Under  Secretary  of  Defense  for  Acquisition  Reform  [DUSD(AR)]  has  been  created.  The 
JLC  anticipate  that  the  DUSD(AR)  will  provide  necessary  change  to  current  acquisition 
policies. 

The  JLC  offer  this  updated  EA  process  as  a  tailored,  streamlined  acquisition  strategy  for 
acquiring  weapon  systems.  The  EA  process  is  consistent  with  current  guidance  and  can 
help  shorten  the  time  between  requirement  genesis  and  weapon  systems  availability.  We 
are  publishing  this  guide  to  encourage  consideration  and  use  of  the  E A  strategy  for  future 
weapon  systems  development  and  when  existing  weapons  are  modified  to  improve  their 
capabilities. 

This  guide  replaces  the  previous  JLC  Guidance  Evolutionary  Acquisition:  An  Alternative 
Strategy  for  Acquiring  Command  and  Control  (C^ )  Systems  published  in  March,  1987.  It  was 
prepared  under  the  direction  of  the  Commandant,  Defense  Systems  Management  College 
(DSMC)  who  has  also  accepted  responsibility  for  keeping  this  document  current. 
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POLICY  STATEMENTS  ABOUT 
EVOLUTIONARY  ACQUISITION 


Background 

Existing  Office  of  Management  and  Bud¬ 
get  (0MB)  and  Office  of  the  Secretary  of 
Defense  (OSD)  policy  statements  have  pro¬ 
vided  a  basis  for  formalizing  acquisition 
processes  used  within  the  Department  of 
Defense  (DoD). 

OMB  Circular  A-109  identified  seven  "Ma¬ 
jor  System  Acquisition  Objectives."  One  of 
those  objectives  is  to: 

"Tailor  an  acquisition  strategy  for  each  pro¬ 
gram,  as  soon  as  the  agency  decides  to  solicit 
alternative  system  design  concepts,  that  could 
lead  to  the  acquisition  of  a  new  major  system 
and  refine  the  strategy  as  the  program  proceeds 
through  the  acquisition  process...  " 

This  OMB  objective  emphasizes  the  desire 
to  develop  a  unique  strategy  for  each  pro¬ 
gram.  It  also  implies  a  requirement  to  pre¬ 
serve  the  program  manager's  (PM)  flexibil¬ 
ity  to  act  appropriately  during  the  acquisi¬ 
tion  process. 

The  DoD  5000  series  of  Directives  (DoDD) 
and  Instructions  (DoDI)  has  been  issued  to 
guide  Defense  Acquisition  personnel  who 
engage  in  major  and  non-major  system  ac¬ 
quisitions.  The  latest  revision  of  DoDD 
5000.1,  "Defense  Acquisition,"  and  DoDI 
5000.2  "Defense  AcquisitionManagement 
Policies  and  Procedures,"  furthers  this  ob¬ 
jective  by  the  following  statements: 


"Acquisition  Strategies  and  Program  Plans. 
Acquisition  strategies  and  program  plans  shall 
be  tailored  to  accomplish  established  program 
objectives  and  to  control  risk  (DoDD  5000.1, 
Part  1,  page  1-4,  paragraph  C.l).  Acquisition 
Program  Content  and  Tailoring.  A  primary  goal 
in  developing  an  acquisition  strategy  shall  be 
to  minimize  the  time  it  takes  to  satisfy  an  iden¬ 
tified  need  consistent  with  common  sense, 
sound  business  practice  and  the  provisions 
of. .DoDD  5000.1  and  DoDI  5000.2...The  num¬ 
ber  of  phases  and  decision  points  must  be  tai¬ 
lored  to  meet  the  specific  needs  of  individual 
programs... Tailoring  must  be  based  on  objec¬ 
tive  assessments  of  a  program's  status,  risks, 
and  the  adequacy  of  proposed  risk  management 
plans  (DoDI  5000.2,  Part  2,  page  2-6,  para¬ 
graph  B.5.).  Tailoring  and  Concurrency.  The 
acquisition  strategy  will  be  tailored  to  match 
the  character  of  the  program  and  allow  the  most 
efficient  satisfaction  of  individual  program  re¬ 
quirements,  consistent  with  the  degree  of  risk 
involved  (DoDI  5000.2,  Part  5,  Section  A,  page 
5-A-4,  paragraph  3.d).  Evolutionary  Acquisi¬ 
tion  and  Preplanned  Product  Improvement.  Al¬ 
ternative  acquisition  strategies  should  be  con¬ 
sidered  for  systems  where  requirements  refine¬ 
ments  are  anticipated  or  where  a  technology  risk 
or  opportunity  discourages  immediate  imple¬ 
mentation  of  a  required  capability.  Alternative 
acquisition  strategies  include  evolutionary  ac¬ 
quisition  and  preplanned  product  improvement. 
Evolutionary  acquisition  is  an  approach  in  which 
a  core  capability  is  fielded,  and  the  system  design 
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has  a  modular  structure  and  provisions  for  fu¬ 
ture  upgrades  and  changes  as  requirements  are 
refined  (DoDI  5000.2,  Part  5,  Section  A,  page 
5-A-5,  paragraph  3.e). " 

Further,  the  Federal  Acquisition  Regulation 
(FAR)  and  the  Defense  Federal  Acquistion 
Regulation  Supplement  (DFARS)  provide 
a  discussion  of  acquisition  management 
principles  as  information  guidance.  They 
support  the  principles  of  flexibility, 
irmovativeness,  and  uniqueness  in  devel¬ 
oping  each  program's  acquisition  strategy. 
The  following  discussion  from  Defense 
Acquisition  Circular  76-43,  "Acquisition 
Management  and  System  Design  Prin¬ 
ciples,"  published  on  February  28,  1983, 
exemplifies  these  acquisition  management 
principles: 

"6.  Acquisition  Strategy 

a.  An  initial  program  strategy  will  be  devel¬ 
oped  by  the  DoD  Component  concerned  for  each 
major  system  acquisition  when  a  new  start  is 
proposed.  The  acquisition  strategy  should  be 
tailored  to  the  unique  circumstance  of  the  pro¬ 
gram.  Proposed  exceptions  to  applicable  DoD 
Directives  and  Instructions  will  be  identified 
in  the  acquisition  strategy  as  it  evolves.  Advice 
and  assistance  should  be  sought  from  business 
and  technical  advisors  and  experienced  man¬ 
agers  of  other  major  system  programs. 

b.  The  acquisition  strategy  is  the  conceptual 
basis  of  the  overall  plan  that  a  program  man¬ 
ager  follows  in  program  exeoution.  It  reflects 
the  management  concepts  that  will  be  used  in 
directing  and  controlling  all  elements  of  the 
acquisition  to  achieve  specific  goals  and  objec¬ 
tives  of  the  program  and  to  ensure  that  the  new 
system  satisfies  the  approved  mission  need.  The 
acquisition  strategy  encompasses  the  entire  ac¬ 
quisition  process  of  the  basic  system,  preplanned 
product  improvements  (PH),  and  post  produc¬ 
tion  support.  The  strategy  must  be  developed 
to  sufficient  detail,  at  the  time  of  issuing 


solicitations  for  the  concept  exploration  phase, 
to  permit  competitive  exploration  of  alterna¬ 
tive  system  design  concepts.  Sufficient  plan¬ 
ning  must  be  accomplished  for  succeeding  pro¬ 
gram  phases,  that  involve  design,  competition 
provisioning  and  support  economies,  and  pro¬ 
duction  source  availability. 

c.  The  acquisition  strategy  must  evolve 
through  an  iterative  process  and  become  in¬ 
creasingly  definitive  in  describing  the  inter¬ 
relationship  of  the  management,  technical, 
business,  resource,  force  structure,  support 
testing,  equipment  standardization,  and  other 
aspects  of  the  program.  Normally,  the 
baselining  and  definition  of  a  program  will 
progress  from  establishment  of  operational 
requirements.... to  afunctional  baseline  (Mile¬ 
stone  I)  to  an  allocated  baseline  (Milestone  II) 
to  a  product  baseline  (Milestone  III). 

d.  Acquisition  programs  will  be  executed  with 
innovation  and  common  sense.  The  flexibility 
inherent  in  DoDD  5000.1  and  DoDI  5000.2 
will  be  used  to  tailor  an  acquisition  strategy 
to  accommodate  the  unique  aspects  of  a  par¬ 
ticular  program,  as  long  as  the  strategy  re¬ 
mains  consistent  with  the  basic  logic  for  sys¬ 
tem  acquisition  problem  solving  and  good 
business  management  principles." 

Moreover,  in  support  of  this  general  guid¬ 
ance,  DoDI  5000.2  specifically  calls  for 
consideration  of  "Evolutionary  Develop¬ 
ment  and  Acquisition  of  Command  and 
Control  Systems,"  and  generally  recog¬ 
nizes  that  Command,  Control  and  Com¬ 
munication  (C^I)  systems  generally  re¬ 
quire  Evolutionary  Acquisition  (EA). 

The  Joint  Logistics  Commanders  (JLC) 
have  endorsed  the  OMB  and  OSD  guid¬ 
ance  in  a  previous  issue  of  this  docimient. 
Now,  given  the  magnitude  of  change  to 
the  world  political  and  military  condition 
and  the  reduced  need  for  active  military 
forces  that  those  changes  generated,  the 
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JLC  believe  a  review  of  the  principles  of  EA 
is  in  order  to  evaluate  the  potential  value 
evolutionary  processes  might  have  when 
used  for  other  than  OI  systems. 

This  document  extends  the  application  of 
EA  processess  beyond  OI  sytems:  it  pro¬ 
vides  new  guidance  about  how  EA  pro¬ 
cesses  can  be  used  to  focus  more  clearly  on 
the  development  of  necessary  military 
equipment  and  the  systems  which  support 
our  field  commanders  and  their  personnel. 
It  does  this  in  the  succeeding  4  Sections: 

Section  2  -  An  Overview  of  Evolutionary 
Acquisition, 

Section  3  -  Characteristics  Which  Indicate 
Consideration  of  an 
Alternative  Acquisition 
Strategy, 

Section  4  -  Adopting  An  Acquisition 

Strategy  which  Accommodates 
Change,  and 

Section  5  -  Guidelines  for  Preparing  the 
Acquisition  Strategy  Report 
for  an  Evolutionary 
Acquisition. 

Use  of  any  acquisition  process  demands 
that  all  personnel  associated  with  the  pro¬ 
gram  provide  their  full  support  and  coop¬ 
eration  in  formulating  and  executing  the 


selected  strategy.  This  is  especially  true 
when  the  strategy  involves  accelerated  ac¬ 
quisition  and  program  risk  shifts. 

An  E  A  program  may  involve  a  number  of 
individuals  and  organizations  outside 
those  reporting  to  the  JLC,  and  the  support 
of  these  persons  and  groups  will  be  crucial 
to  program  success.  The  JLC  urge  all  orga¬ 
nizations  and  individuals  within  them  who 
are  involved  in  acquisition  processes  be¬ 
come  familiar  with  the  principles,  advan¬ 
tages  and  potential  pitfalls  which  may  ac¬ 
company  the  use  of  the  EA  processes  out¬ 
lined  in  this  guide. 

Establishing  effective  patterns  of  interac¬ 
tion  with  external  organizations  involved 
in  EA  processes  may  be  difficult:  use  of  EA 
will  require  review  of,  and  perhaps  modi¬ 
fication  to,  established  relationships  be¬ 
tween  those  organizational  entities  in¬ 
volved.  The  JLC  will,  if  necessary,  assist 
subordinate  commanders  and  their  PMs  in 
their  efforts  to  achieve  effective  patterns  of 
interaction  with  organizational  entities  in¬ 
volved. 

Choosing  an  appropriate  acquisition  strat¬ 
egy,  whether  it  be  evolutionary  or  any  other 
kind,  will  not  by  itself  insure  a  successful 
program.  Rather,  excellence  of  manage¬ 
ment  and  strong  support  of  all  who  are  in¬ 
volved  are  additional  conditions  essential 
to  success. 
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AN  OVERVIEW  OF 
EVOLUTIONARY  ACQUISITION 


Background  Studies 

Two  major  studies^  of  past  Command  and 
Control  systems  have  found  that  the  use 
of  standard  acquisition  approaches  de¬ 
scribed  in  detail  in  Department  of  Defense 
Directives  (DoDD)  and  Instructions  (DoDI) 
have  often  had  unsatisfactory  results. 

The  systems  considered  in  these  studies 
were  large,  software  dominated  informa¬ 
tion  systems  intended  to  aid  operational 
commanders  in  performing  their  command 
and  control  functions. 

Difficulties  arose  primarily  because,  espe¬ 
cially  for  command  and  control  systems,  it 
was  often  impossible  to  define  detailed 
operational  capabilities  or  functional  char¬ 
acteristics  for  the  complete  system  before 
undertaking  full  scale  development,  now 
called  Engineering  and  Manufacturing 
Development  (EMD). 

Studies  currently  underway^  have  exam¬ 
ined  the  acquisition  environment  likely  to 
emerge  from  changed  threat  perception, 
rapid  world  economic  change  and  its  as¬ 
sociated  technological  advances  and  re¬ 
alignments.  It  appears  that  rapid  change  to 


most  elements  which  affect  the  acquisition 
process  environment  will  preclude  those 
long  periods  of  stability  necessary  to  de¬ 
velop  clear  definition  of  system  opera¬ 
tional  concepts,  capabilities  and  functional 
characteristics  prior  to  entering  EMD.  This 
implies  the  extension  of  Evolutionary  Ac¬ 
quisition  (EA)  processes  to  systems  other 
than  OI. 

Whenever  EMD  of  any  complete  system 
is  begim  without  clear  definition  of  sys¬ 
tem  operational  concepts,  capabilities  and 
functional  characteristics;  it  is  very  likely 
that  the  development  process  will  be  long, 
costly  and  unstable.  TTie  developed  sys¬ 
tem  will  then  be  unsatisfactory  and  logis- 
tically  unsupportable. 

Recent  changes  in  world  conditions  have 
materially  affected  the  environment  in 
which  defense  acquisitions  will  take  place: 

•  The  former  emphasis  on  a  European 
continental  threat,  the  Soviet  Union, 
has  been  replaced  by  multiple  and 
constantly  changing  threats  in  terms 
of  both  threat  location  and  the  weap¬ 
ons  adversaries  might  use. 


\  '"Report  of  the  Defense  Science  Board  Task  Force  on  Command  and  Control  Systems  Management”,  July  1978,  Offfice  of 
the  Under  Secretary  of  Defense  Research  and  Engineering,  Washington  D.C.  and  "Command  and  Control  (C^)  Systems 
Acquisition  Study  Final  Report”,  September  1, 1982,  The  Armed  Forces  Communications  and  Electronics  Association, 
Falls  Church,  Virginia. 

Studies  in  progress:  Armed  Forces  Commuiucation  and  Electronic  Association  and  Defense  Systems  Manage¬ 
ment  College. 


•  In  a  fiscally  constrained  economy  it 
is  likely  that  new  system  starts  will 
be  few,  modifications  to  current  sys¬ 
tems  will  be  the  norm,  and  use  of  non- 
developmental  items  (NDIs)  will  be 
emphasized. 

•  A  shortened  period  of  technological 
advances,  and  ready  market  avail¬ 
ability  of  commercial  off-the-shelf 
(COTS)  components,  changes  the  po¬ 
tential  to  make  performance  trade¬ 
offs  and  provides  opportunities  to 
achieve  cost  effectiveness  and  sched¬ 
ule  improvements.  Under  such  cir¬ 
cumstances  defense  systems  ad¬ 
vances  may  likely  be  incremental 
rather  than  generational:  improve¬ 
ments  in  efficiency  and  effectiveness 
of  existing  systems  more  than  their 
total  replacement  by  entirely  new 
platforms  and  tightly  integrated 
equipment. 

The  ability  to  respond  to  change  has  be¬ 
come  an  important  element  of  Defense  Sys¬ 
tem  Acquisition  Strategy.  The  above  stud¬ 
ies  all  have  recommended  the  use  of  an  EA 
strategy  to  permit  orderly,  timely  and  effi¬ 
cient  development  of  effective  defense  sys¬ 
tems  for  the  type  of  environment  in  which 
new  defense  acquisitions  will  be  operated 
and  maintained. 

Evolutionary  Acquisition  (EA)  Defined 

The  EA  process  is  defined  as  follows: 

A  strategy  for  use  when  it  is  anticipated  that 
achieving  the  desired  overall  capability  will  re¬ 
quire  the  system  to  evolve  during  development, 
manufacture  or  deployment. 


Among  categories  of  factors  which  influ¬ 
ence  EA  are  requirements  uncertainties, 
technical  uncertainties,  funding  availabil¬ 
ity,  schedule  problems,  interoperability  and 
commonality  requirements,  the  need  in 
some  kinds  of  systems  for  continuous  user 
involvement,  and  instabilities  due  to  envi¬ 
ronment.  An  evolutionary  process  may  be 
especially  effective  when  change  to  any  of 
these  factors  is  likely  during  the  time  pe¬ 
riod  of  system  development. 

The  major  approach  which  underlies  EA  is 
encouraging  early  fielding  of  a  well  defined 
core  capability  in  response  to  a  validated 
requirement.  This,  while  planning  actions 
which  will,  within  an  approved  architec¬ 
tural  framework,  enhance  that  core  and 
ultimately  provide  a  complete  system  with 
the  required  overall  capabilities.  Senior 
leadership  must  be  actively  involved  in 
such  a  strategy. 

Each  incremental  capability  to  be  acquired 
is  treated  as  a  tailored  individual  acquisi¬ 
tion.  Scope  and  content  result  from  both 
continuous  feedback  from  the  developer, 
independent  testing  agencies,  the  user  (op¬ 
erating  forces)  and  supporting  organiza¬ 
tions;  and  application  of  desirable  technol¬ 
ogy  within  the  constraints  of  time,  require¬ 
ments,  cost  and  risk. 

Characteristics  of  EA  are: 

•  A  general  description  of  the  functional 
capability  desired  for  the  full  system.^ 

•  A  concise  statement  of  operational 
concepts  for  the  full  system. 

•  A  flexible,  well-planned  overall  archi¬ 
tecture,"^  to  include  process  for  change. 


^  The  lack  of  specificity  and  detail  in  identifying  the  final  system  capability  distinguishes  EA  from  other  incremental 
strategies. 

The  system  architecture  defines  the  partitioning  of  system  components,  flow  of  data,  flow  of  control,  timing,  and 
throughput  relationships,  interface  layering  and  protocol  standards.  A  flexible  architecture  requires  long-term  tolerance 
to  change.  (See  '"A  New  Process  for  Acquiring  Software  Architecture",  by  Thomas  F.  Saunders,  Dr.  Barry  H.  Horowitz, 
Matt  L.  Mleziva,  M92B0000126  The  MITRE  Corporation,  November  1992.) 
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which  will  allow  the  system  to  be 
designed  and  implemented  in  an  in¬ 
cremental  way  with  minimum  regres¬ 
sion  testing.  Recent  advances  in  open 
systems  and  domain  architectures  are 
enabling  change  at  reasonable  cost 
and  impact. 

•  Apian  for  incrementally  achieving  the 
desired  total  capability  which  ad¬ 
heres  to  life-cycle  cost  effectiveness. 

•  Early  definition,  funding,  develop¬ 
ment,  testing,  fielding,  supporting 
and  operational  evaluation  of  an  ini¬ 
tial  increment  of  operational  capabil¬ 
ity. 

•  Continual  dialogue  and  feedback 
among  users,  developers,  supporters 
and  testers. 

The  kinds  of  uncertainties  which  preclude 
detailed  planning  and  the  degree  of  user 
or  developer  involvement  required  during 
the  evolutionary  process  determine  which 
major  classes  of  EA  best  fit  any  particular 
program.  These  kinds  of  uncertainties  also 
determine  how  incremental  (evolutionary) 
acquisition,  which  was  previously  called 
Pre-Planned  Product  Improvement  (P^I), 
will  be  managed  in  each  class. 

•  The  first  EA  class  is  characterized  by 
requirements  which  are  certain  to 
change,  are  large  in  scope  (such  as  are 
encountered  in  the  development  of 
new  command  and  control  systems); 

•  The  second  EA  class  is  characterized 
by  technological  uncertainties  (such 


as  are  encountered  in  new  sensor  and 
weapon  systems);  and 
•  The  third  E  A  class  is  characterized  by 
planning,  programming  and  budget¬ 
ing  (PPBS)  imcertainties  (such  as  cost, 
schedule,  budgeting  and  logistics). 

Successful  Evolutionary  Acquisition 

Executing  EA  programs  successfully  will 
require  some  change  in  relationships 
among  the  various  agencies  involved  in  the 
acquisition  process,  and  practices  used 
under  conditions  of  long-term  stability.  An 
important  change  is  the  need  for  much 
closer  interactive  relationships  among: 

•  forces  in  the  field  (commanders  and  in¬ 
dividual  troops),  and  the  user  representa¬ 
tives  (operators  and  maintainers)  during 
system  design  and  development; 

•  independent  testers  (who  will  ensure  test¬ 
ability  of  the  system  and  all  its  elements  as 
capabilities  are  continuously  enhanced); 

•  developer  (including  Industry);  and 

•  PPBS  that  must  react  more  quickly  to  the 
changing  fiscal  requirements  implicit  in  the 
EA  process. 

A  primary  requisite  for  successful  EA  is  recog¬ 
nition  of  the  need  to  develop  strategies  which 
facilitate  change. 

The  chapters  which  follow  will  detail 
changes  in  current  practice  and  provide 
guidance  on  how  they  might  be  achieved. 
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standard  Approach 

Insight  at  ''Beginning'*  and  "End" 


Level  of  With  Large  Gap  In  Between 

User  Insight 


Doesn't  Work  for 
Unprecedented 
Systems  or 
Rapidly  Changing 
Environments 


Evolutionary  Approach 


Early  and  Continuous  User 


•  Provides  Mechanism  to  Solicit  User  and  Technology 
Feedback  and  Make  Required  Adjustments 

But, 

•  Uncertainty  Makes  It  Difficult  to  Accurately  Quantify 
Cost,  Schedule  for  this  Activity  In  “Advance" 


Figure  2-1.  Evolutionaiy  Acquisition  Overview 
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CHARACTERISTICS  WHICH  INDICATE 
CONSIDERATION  OF  AN 
ALTERNATIVE  ACQUISITION  STRATEGY 


Background 

To  help  develop  factors  which  indicate  a 
need  to  consider  alternative  acquisition 
strategies,  a  group  of  very  experienced  ac¬ 
quisition  managers  was  asked  to  respond 
to  the  question  "What  are  the  factors  which 
would  cause  you  to  select  a  particular  Acquisi¬ 
tion  strategy?" 

Factors  were  identified  in  six  (6)  categories 
of  equal  importance,  which  they  believed 
would  affect  the  choice  of  an  acquisition 
strategy.  The  factor  categories  were: 

Requirements 

•  Are  there  uncertainties  about  require¬ 
ment  stability  or  requirement  details? 
Are  requirements  likely  to  evolve, 
grow  or  change  because  of 

->  an  evolving  threat  or  change  to  pro¬ 
jected  battle  environments, 

->  an  uncertain  operational  concept, 
->  uncertainty  in  ihe  final  capability  to 
be  achieved,  or 

->  change  to  the  objectives  or  goals  to 
be  met? 

•  Are  there  size  and  complexity  uncer¬ 
tainties? 

•  Has  the  requirement  been  well  com¬ 
municated? 

•  Is  user  feedback  during  development 
necessary  to  "tune"  final  require¬ 
ments? 


Technology 

•  What  are  the  technology  states  of  the 
art?  What  states  of  the  art  and  of 
practice  are  required?  What  techni¬ 
cal  innovations  will  be  necessary? 

•  What  is  the  foreseeable  time-line  of 
technological  change?  How  uncer¬ 
tain  is  the  technology  (how  unstable 
is  it  and  what  changes  in  technologi¬ 
cal  opportunities  are  likely)?  What 
are  the  maturities  of  the  required 
technology  infrastructures?  And, 
what  is  known  about  achievable 
trade-off  bases? 

•  Are  there  uncertainties  in  the  perfor¬ 
mance  characteristics  required? 
What  is  the  pattern  of  system  func¬ 
tional  interfaces?  Must  the  system 
architecture  support  system  perfor¬ 
mance  growth  and  must  the  system 
be  scalable? 

•  How  available  are  test  and  support 
assets? 

•  Is  the  system  "software  dominated?" 

User  Involvement 

•  How  many  users  are  there  and  what 
are  the  characteristics  of  the  user 
groups? 

•  Is  there  likely  to  be  a  change  in  the 
composition  of  "users?" 
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•  What  degree  of  user  involvement  is 
"necessary"  and  how  much  user 
feedback  is  essential? 

Schedule 

•  What  is  the  user's  time-line? 

•  Is  there  urgency  in  the  schedule  (is 
something  urgently  needed  in  the 
field)?  How  urgently  is  a  short-term 
capability  required?  Are  there  prob¬ 
lems  or  uncertainties  in  meeting  the 
schedule?  Is  the  Initial  Operating 
Capability  firm  or  is  there  need  to 
consider  systems  growth  from  the 
program's  outset? 

•  Are  schedule  instabilities  inherent  in 
the  program? 

Funding 

•  Are  there  budget  uncertainties  (insta¬ 
bilities)  regarding  near-  and  long¬ 
term  funding  requirements,  funding 
types  and  availabilities? 

•  Is  it  likely  that  implementation  cost 
assumptions  are  unstable?  Are  there 
uncertainties  or  problems  in  likely 
cost  or  affordability?  Are  cost  and 
schedule  realism  firmly  in  hand? 

•  Is  the  likely  size  of  the  buy  fixed? 
Would  changed  quantities  result  in 
changed  affordability? 

Other  Constraints 

•  What  systems  are  being  replaced? 
What  is  the  status  of  other  affected 
programs?  Is  there  a  need  to 
reengineer  or  upgrade  older  systems? 

•  What  commonalities  and  interoper¬ 
abilities  with  other  systems  are  nec¬ 
essary  and  what  is  their  maturity? 


•  What  interfaces  are  there  with  other 
agencies  and  concepts?  What  support 
agencies  and  concepts  interface  with 
the  system?  What  requirements  are 
there  for  capability  to  repair  or 
change  the  fielded  system? 

•  Is  there  existing  or  modifiable  com¬ 
mercial  capability?  Are  there  Non- 
Developmental  Item  (NDI)  compo¬ 
nents  commercially  available?  Are 
there  commercial  sources  for  compo¬ 
nents  or  equipment? 

•  Is  incremental  development  indicated 
because  of  likely  instabilities  in  the  re¬ 
quirements,  environment  or  tech¬ 
nologies  available  during  the  planned 
developmental  program? 

Review  of  the  factor  categories  indicated 
that  some  key  conditions  appeared  to  ex¬ 
ert  major  influence  on  the  acquisition  strat¬ 
egy  selection.  They  were: 

Uncertainty 

There  may  be  changes  to  the  factor  catego¬ 
ries  during  the  period  of  system  develop¬ 
ment  and  use,  which  might  force  change 
in  system  design  in  order  to  achieve  per¬ 
formance  or  other  objectives;  or  there  is 
uncertainty  about  how  exactly  to  apply 
current  knowledge  to  achieve  system  in¬ 
tegrity;  or  both.^ 

Lack  of  Knowledge 

There  are  no  ready  mechanisms  (tech¬ 
niques,  processes,  infrastructures,  data) 
available  in  one  or  more  factor  categories 
to  permit  achievement  of  all  desired  sys¬ 
tem  capabilities.  This  situation  is  very  likely 
to  change  during  the  period  of  system  de¬ 
velopment;  or  some  new  mechanisms  will 


'  A  circumstance  which  can  be  paraphrased  as:  "We  know  how  to  do  what  is  necessary  in  general,  but  we  are  unsure 
how  to  apply  it  to  the  job  at  hand,  and  we  do  not  know  if  the  circumstances  of  appl)dng  that  knowledge  will  change 
during  the  hfe  of  the  development  and  use." 
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need  to  be  devised;  or  changes  in  circum¬ 
stance  of  system  usage  will  change  the  way 
in  which  existing  or  developing  mecha¬ 
nisms  can  be  applied.^ 

Omens  of  Change 

There  is  reason  to  believe  that  change  to 
the  factors  will  occur  in  a  time  frame 
shorter  than  the  system  development  pro¬ 
cess  requires.  Because  those  changes  would 
affect  system  architecture  as  well  as  the 
system  capability  (each  might  need  to 
evolve)  they  must  be  considered  in  formu¬ 
lating  an  acquisition  strategy.^ 

The  major  reason  to  select  an  alternative 
acquisition  development  strategy  versus  a 
classical  development  strategy  is  the  need 
to  accommodate  continuous  change  that  re¬ 
sults  from  the  major  influences  enumerated 
above. 

Review  of  Weapon  Systems  Characteris¬ 
tics 

Given  an  acquisition  environment  charac¬ 
terized  by  uncertainty  in  requirements  and 
technology,  it  is  unlikely  that  details  of 
weapon  systems  development  activity  can 
be  defined  in  detail  very  far  in  advance  of 
the  required  activity.  Even  system  design 
and  interface  specifications  with  other  sys¬ 
tems,  also  under  development,  will  require 
redefinition  as  responses  to  changed  situa¬ 
tions  are  recognized. 

Moreover,  development  programs  which 
seek  to  improve  existing  weapon  systems 
capabilities  will  display  characteristics  nor¬ 
mally  associated  with  shorter  term  sequen¬ 
tial,  incremental  product  development  ac¬ 
tivity,  rather  than  those  associated  with  the 


long-term  generational  weapon  system 
developments  which  dominated  past  ac¬ 
quisition  activities. 

For  these  reasons,  alternative  approaches 
to  weapon  systems  development  may  be¬ 
come  the  preferred  methodology  for  many 
kinds  of  acquisitions.  Specifically,  systems 
which  are  characterized  by  one  or  more  of 
the  following  statements  are  candidate  sys¬ 
tems  for  alternative  acquisition: 

•  Supports  a  unified  or  specified  com¬ 
mand  which  connects  with  higher, 
lower  and  collateral  commands  as 
part  of  an  uncertain  interoperability 
relationship /requirement,  or  is  re¬ 
quired  for  interoperability  with 
multi-service  or  multi-national  sys¬ 
tems  that  are  nonstandard  or  imder 
development. 

•  Fulfills  one  or  more  operational  mis¬ 
sions  or  part  of  an  overarching  doc¬ 
trine  or  strategy  that  is  under  revision 
or  in  a  state  of  flux. 

•  Is  tightly  coupled  with  particular  op¬ 
erational  settings  and  thus  aligned 
with  specific  geographical  param¬ 
eters,  ranges  of  threats,  and/or  spe¬ 
cific  doctrines. 

•  Meets  the  specific  needs  and  desires 
of  specific  individual  operational 
commanders. 

•  Is  highly  adaptable  to  meet  the  many 
demands  a  commander  can  place 
upon  them  under  the  wide  range  of 
circiunstances  inherent  in  a  battlefield 
environmert. 

•  Has  limited  access  after  deployment 
(e.g.,  satellite  systems). 

•  Will  require  continuing  research  and 
development  after  deployment  to 
overcome  technological  shortfalls. 


^  A  situation  which  might  be  paraphrased  as:  ''We  know  what  to  do  to  achieve  success,  but  not  how  to  do  it." 

^  A  situation  which  might  be  summarized  as:  "We  know  what  to  do,  but  we  expect  that  to  change  during  the  time  we 
are  in  the  process  of  doing  it." 
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•  Are  vulnerable  to  evolving  counter¬ 
measures. 

•  Is  primarily  command,  control  and 
communication  (C^I)  system  devel¬ 
oped  to  assist  operational  command¬ 
ers  understand  and  communicate 
information  concerning  hostile  and 
friendly  forces,  select  an  effective 
course  of  action,  and  monitor  execu¬ 
tion  of  the  implementing  operational 
orders. 

•  Is  computer-software  dominant. 

•  When  only  one  system  is  required. 

•  Performs  acceptably  with  imperfect 
information,  and  performance  should 
degrade  gradually  rather  than  cata¬ 
strophically  when  damaged  or 
stressed  beyond  design  limitations. 


The  activities  and  actions  required  for  suc¬ 
cessful  EAare  described  in  the  next  section. 

Despite  the  uncertainties  that  characterize  a 
program  utilizing  an  alternative  approach,  it 
is  of  paramount  importance  that  each  design 
increment  be  preceded  by  a  complete,  and  un¬ 
ambiguous  articulation  of  system  requirements 
for  that  particular  increment.  Additionally,  an 
adequate  understanding  of  the  "final"  system's 
capability  must  be  known  in  order  to  provide 
for  incremental  designs  that  will  allow  future 
enhancements  without  negating  previous  de¬ 
sign  efforts  (see  Chapter  4).  If  either  of  these 
components  are  lacking,  then  acquisition  design 
initiation  should  not  proceed. 
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4 

ADOPTING  AN  ACQUISITION  STRATEGY 
WHICH  ACCOMMODATES  CHANGE 


Activities  and  Actions  Required  to 
Implement  Evolutionary  Acquisition 
(EA)  Approaches 

Most  future  defense  acquisitions  will  need 
to  accoxmt  for  and  facilitate  change.  Execut¬ 
ing  a  strategy  which  can  deal  with  imcer- 
tainty  and  is  appropriate  for  periods  of 
widespread  change  will  require  adjust¬ 
ments  to; 

-  Relationships  between  participants  in 

the  acquisition  process; 

-  Management  procedures  and  docu¬ 
ments;  and 

-  Tailoring  the  strategy  to  the  type  of 
system  (C^  weapon,  administrative, 
etc.)  acquired. 

Such  adjustments  will  provide 

•  Flexibility  necessary  for  adequate  re¬ 
sponse  to  requirements  changes,  re¬ 
sulting  from  learning  that  occurs  dur¬ 
ing  the  development  process; 

•  For  rapid  progress  through  the  vari¬ 
ous  steps  in  the  acquisition  process 
as  each  system  capability  increment 
is  developed; 

•  Sound  technical  bases  which  en¬ 
courage  incremental  equipment  ca¬ 
pability  upgrade  to  exploit  innova¬ 
tive  new  technologies  and  increas¬ 
ingly  sophisticated  and  reliable 
commercial  off-the-shelf  (COTS), 
and  reusable,  systems  and  system 


components,  without  excessive 
time  penalties  associated  with  re¬ 
work  and  regression  testing;  and 
•  For  robust  system  interfaces  config¬ 
ured  to  permit  continued  system  in¬ 
terconnection  and  data  exchange 
among  specified  systems  as  they 
evolve. 

To  permit  appropriate  exercise  of  manage¬ 
ment  oversight,  all  changes  to  present  re¬ 
lationships  and  practices  must  be  taken 
openly.  In  particular,  changed  procedures 
and  relationships  still  must  facilitate  con¬ 
trol  of  requirements  growth,  assure  timely 
delivery  of  required  capabilities,  provide 
for  necessary  operational  testing,  and  al¬ 
low  for  competition  among  qualified 
suppliers. 

Approaches  to  EA  heighten  (rather  than 
obviate)  the  need  for  early  program  plan¬ 
ning  and  for  technical  and  support  engi¬ 
neering  activity.  Clearly,  the  organic  and 
commercial  logistics  support  infrastruc¬ 
ture,  which  is  also  evolving,  must  be  con¬ 
sidered  so  that  both  initial  capabilities  and 
subsequent  increments  can  be  cost-effec¬ 
tively  supported,  to  the  levels  of  perfor¬ 
mance  specified,  beginning  at  introduction. 
Requirements  definition,  technology  and 
threat  forecasting,  system  architectural 
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planning,  and  funding  availability  pros¬ 
pects  over  an  extended  program  develop¬ 
ment  life  span  are  all  necessary  to  set  the 
framework  of  acquisition. 

Key  areas  where  changes  to  present  prac¬ 
tice  are  required  are  discussed  below. 

Relationships  Among  the  Acquisition 
Executive,  User  and  User  Surrogate, 
Developer  and  Tester 

Relationships  among  the  major  entities 
may  be  rather  formal  in  conventional  ac¬ 
quisition  programs.  Negotiations  between 
them  may  be  conducted  at  arm's  length. 
The  roles  of  each  participant  need  redefi¬ 
nition  and  adjustment  to  achieve  a  success¬ 
ful  EA.  Closer,  more  cooperative  relation¬ 
ships  will  be  needed  to  achieve  necessary 
harmony  in  five  areas: 

1.  System  Operational  Capabilities:  In 

conventional  system  acquisition,  a 
surrogate  user  frequently  assumes 
the  primary  role  in  specifying  desired 
system  operational  requirements. 
Depending  on  individual  service  pro¬ 
cedures,  the  primary  field  user  may 
be  removed  from  the  acquisition  pro¬ 
cess.  When  EA  processes  are  used  to 
acquire  systems  characterized  by  re¬ 
quirements  uncertainties,  or  which 
are  unprecedented,  a  major  premise 
is  that  the  field  user  plays  the  major 
role  in  formulating  operational  re¬ 
quirements  and  in  defining  detailed 
system  characteristics  when  opera¬ 
tional  requirements  have  been  de¬ 
fined.  Each  program  will  need  to  de¬ 
fine  suitable  roles  for  all  participants. 
Individual  roles  among  participants 
can  become  quite  complex,  especially 
when  users  are  members  of  a  Service 
different  from  that  of  the  developer. 
Because  relationships  are  critical  to 


program  success,  they  should  be  suit¬ 
ably  formalized  by  Memoranda  of 
Understanding  or  Agreement. 

2.  Operational  Test  and  Evaluation:  A 

key  premise  in  EA  processes  is  that 
systems  tests  are  made  incrementally 
on  each  element  of  system  capability. 
Initial  testing  is  accomplished  on  the 
first  incremental  system  configura¬ 
tion  and  involves  an  investigation  of 
architecture  growth  capability;  test¬ 
ing  continues  on  subsequent  configu¬ 
rations  as  they  become  available.  Tlie 
tests  determine  whether  the  system, 
as  configured,  meets  the  operational 
requirements  the  user  has  specified. 

Each  Service  has  an  organization  re¬ 
sponsible  for  independent  opera¬ 
tional  test  and  evaluation.  When  the 
user  operates  a  system,  that  user  be¬ 
comes  a  critical  part  of  the  total  sys¬ 
tem  and  greatly  influences  its  perfor¬ 
mance.  When  independent  testers 
perform  tests  with  user  groups,  not 
only  are  test  results  more  likely  to  rep¬ 
resent  real  capabilities,  but  both  the 
user  and  the  developer  gam  imder- 
standing  of  the  system  capabilities. 
That  shared  information  is  critical  to 
vahdating  (or  redefining)  operational 
requirements  for  those  system  incre¬ 
ments  which  are  to  follow. 

Because  the  operational  tests  are  so 
important  in  the  process  of  evolving 
requirements  and  introducing  incre¬ 
ments  of  system  operating  improve¬ 
ments,  which  distinguishes  evolu¬ 
tionary  approaches  from  more  clas¬ 
sical  weapon  systems  acquisition  pro¬ 
cesses,  it  is  imperative  that  operational 
testers  and  evaluators  become  deeply 
involved  early  and  maintain  continu¬ 
ous  direct  liaison  with  developer  and 
user.  Early,  continuous  involvement 
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facilitates  integrated,  appropriate, 
and  timely  operational  testing  essen¬ 
tial  to  successful  system  develop¬ 
ment. 

In  conventional  acquisition  processes, 
developers  and  users  may  have  less 
frequent  interaction  during  the  devel¬ 
opment  process  than  during  EA  pro¬ 
cesses.  Each  EA  process  depends  on 
just  such  close  and  continued  inter¬ 
action.  Developers,  users  and  those 
who  will  support  the  system  when 
deployed  must  work  closely  together 
over  the  course  of  the  development 
activity.  For  systems  with  require¬ 
ments  uncertainties,  provision  for 
user  prototypes  and  testing  at  beta 
sites  should  be  included  within  the 
acquisition  strategy. 

Use  of  EA  approaches  is  likely  to 
make  necessary  some  redefinition  of 
the  process  of  operational  testing  and 
evaluation.  Specifically,  there  may  be 
an  increased  use  of  contractor  testing, 
especially  for  systems  which  are  soft¬ 
ware  intensive.  This  issue  must  be 
addressed  in  the  Test  and  Evaluation 
Master  Plan  at  program  inception. 
The  objective  of  operational  test  and 
evaluation  should  be  to  exploit  inte¬ 
grated  testing  without  loss  of  critical 
independence  of  contractor /devel¬ 
oper/user  perspective  and  their 
subsequent  input  to  the  ongoing  de¬ 
velopment  process. 

3.  Program  Review  and  Approval:  In 
conventional  acquisition  there  are 
only  a  few  instances  (normally  at 
major  program  milestones)  when  a 
program  manager  (PM)  is  required 
to  gain  decision  authority  approval 
to  proceed.  The  EA  processes  might 
require  milestone  decision  author¬ 
ity  approval  for  each  increment  of 
capability,  perhaps  at  each  of  several 


stages  in  the  development  program. 
Use  of  EA  processes  will  require  con¬ 
siderable  streamlining  of  the  ap¬ 
proval  process.  For  some  programs, 
when  a  final  configuration  can  be 
defined  in  detail,  the  total  system 
might  be  validated  as  one  require¬ 
ment  and  each  increment  treated  as  a 
"release,"  provided  the  program  per¬ 
formance  and  cost  thresholds  are 
maintained. 

4.  Program  Management:  In  conven¬ 
tional  acquisition,  a  program  office  is 
frequently  established  only  after 
considerable  preliminary  planning 
has  been  completed  and  the  program 
is  really  underway.  Under  such  cir¬ 
cumstances,  it  may  not  be  possible  to 
begin  the  program  with  the  numbers 
of  experienced  staff  at  desirable  lev¬ 
els  of  expertise.  Use  of  EA  demands 
that  a  fully  capable  program  office  be 
established  very  early  because: 

-  the  acquisition  strategy  must  be  de¬ 
fined  early, 

-  the  roles  of,  and  relationships  be¬ 
tween,  the  key  stakeholders  must  be 
negotiated  early, 

-  the  program  sponsor  wiU  need  pro¬ 
gram  office  support  in  defining  the 
fundamental  architecture  and  sup¬ 
port  structure  which  underlies  the 
complete  system,  and 

-  early  delivery  of  a  core  capability 
and  early  feedback  on  its  perfor¬ 
mance  are  required. 

Another  consideration:  the  program 
office  must  generally  be  staffed  more 
heavily  to  allow  it  to  manage  all 
phases  of  the  acquisition  cycle  con¬ 
currently,  since  using  an  evolutionary 
process  may  find  several  increments, 
in  different  stages  of  acquisition,  xm- 
der  development  at  any  one  time. 
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5.  Competition  in  Contracting:  Use  of 
EA  requires  consideration  of  four 
closely  related  areas  of  work  -  system 
architecture;  developing  and  main¬ 
taining  off-line  development,  test  and 
support  facilities;  system  configura¬ 
tion  management;  and  logistic  sup¬ 
port.  These  areas  of  work  may  con¬ 
tinue  not  only  throughout  acquisition 
but  also  throughout  the  systems  use¬ 
ful  lifetime,  since  the  system  will  con¬ 
tinue  to  evolve  through  use  experi¬ 
ence.  Because  it  is  important  that  con¬ 
tinuity  be  maintained  in  each  of  these 
functional  areas,  either  the  functions 
must  be  provided  directly  by  the 
goverment,  or  any  contractor  per¬ 
forming  a  function  must  be  retained 
for  some  number  of  years.  While  con¬ 
tractors  can  be  changed  occasionally 
without  undue  program  impact,  fre¬ 
quent  change  in  responsible  agent  or 
staff  will  likely  be  highly  disruptive^ 

The  task  of  developing  operational 
applications  utilizing  the  system  ar¬ 
chitecture  as  part  of  each  increment 
to  the  system  operational  capability 
should  not  be  significantly  affected  by 
change  in  management  or  staff.  The 
inefficiencies  of  new  contractors 
learning  the  system  should  be  ame¬ 
liorated  by  a  flexible  system  architec¬ 
ture  which  increases  positive  effects 
of  competition. 

Changes  to  Current  Management 
Procedures  and  Documents 

System  Planning  and  System 
Architecture 

Significant  effort  is  required  early  in  the 
program  to  permit  adopting  a  strategy 


which  accommodates  change.  It  will  be 
necessary  to  analyze  and  explore  the  likely 
directions  of  change  over  the  life  of  the  pro¬ 
gram;  although  omniscience  is  unlikely, 
reasonable  understanding  can  be  gained  of 
likely  directions  for  change  in  threat,  op¬ 
erational  employment  and  deployment, 
technological  evolution  and  the  likely 
availability  of  suitable  commercial  prod¬ 
ucts,  and  development  of  interface  stan¬ 
dards  and  funds.  All  of  these  elements  are 
essential  to  structure  the  content  of  acqui¬ 
sition  increments,  the  pace  of  progress,  and 
to  select  an  architectural  framework  which 
facilitates  evolving  the  system  capabilities 
over  the  life  of  the  program. 

Recent  developments^  offer  increased  po¬ 
tential  to  exploit  technological  innovation 
and  COTS  products,  thus  making  compe¬ 
tition  easier  and  potentially  very  produc¬ 
tive.  The  choice  of  architecture  is  a  crucial 
issue.  It  must  be  tailored  to  the  problem  and 
mission  domains  but  also  provide  for  the 
most  likely  sets  of  change.^  That  is,  the  de¬ 
velopment  process  needs  to  incorporate  the 
means  for  changing,  i.e.,  evolving,  the  sys¬ 
tem  architecture  itself  over  the  life  of  the 
program. 

In  addition  to  data  processing  and  infor¬ 
mation  exchange  architectures,  a  plan  is 
required  to  ease  platform  installation  and 
modification  and  thus  facilitate  the  capa¬ 
bility  for  a  system  to  evolve  over  its  life 
cycle. 

Control  and  Stability  of  the 
Development  Process 

Proper  process  control  must  be  provided 
for  in  EA  processes.  It  is  important  to  de¬ 
fine  precisely  the  developmental  incre¬ 
ments  and  what  system  performance  they 


'  It  may  be  preferable  for  the  government  to  perform  the  functions  with  in-house  government  staff. 

^  Some  of  these  developments  are:  layered  architectures,  formal  specification  languages,  open  bus  and  network 
interconnection  techniques  and  standards,  fourth  generation  computer  languages  and  object  oriented  design. 

^  We  are  not  able  to  design  a  single  architecture  to  accommodate  all  types  of  change  over  extended  period  of  time. 
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will  achieve.  Doing  so  will  provide  a  basis 
for  review  of  changing  functional  require¬ 
ments  that  appear  during  the  development 
process.  Change  to  functional  requirements 
(especially  additions  to  current  require¬ 
ments)  can  be  controlled  by  accepting  only 
very  important  changes.  The  philosophy  of 
permitting  only  crucial  requirement 
changes  is  essential  because: 

Feedback  on  effectiveness  and  suitability 
from  actual  operations  and  maintenance  is 
almost  always  required  to  determine  the 
value  of  proposed  changes  with  any  degree 
of  certainty.  For  programs  with  short  times 
between  development  increments,  defer¬ 
ring  requirements  changes  until  the  next 
program  increment  might  be  a  better 
course  of  action  because  it  preserves  sched¬ 
ule  and  does  not  place  delivery  and  field¬ 
ing  plans  at  risk.  However,  preserving 
schedule  is  of  little  value  if  feedback  indi¬ 
cates  an  inability  to  meet  or  sustain  speci¬ 
fied  performance  thresholds  or  a  lack  of 
logistics  supportabiiity. 

When  users  can  identify  frequently  chang¬ 
ing  requirements,  then  EA  may  be  an  ap¬ 
propriate  strategy  if  multiple  configura¬ 
tions  can  be  managed  and  supported.  Evo¬ 
lutionary  processes  provide  for  later  stages, 
when  such  changes  can  be  incorporated  if 
still  required. 

The  need  to  manage  requirements  changes 
is  perhaps  greatest  when  change  affects 
software  in  development.  It  is  often  pos¬ 
sible  to  effect  a  performance  change 
through  a  change  to  the  system  software. 
There  is  a  widely  held  belief  that  software 
changes  are  easy  to  accomplish,  and  that  a 
change  in  requirements  results  in  only  mi¬ 
nor  software  modification.'*  In  reality,  the 


further  along  the  development  process  is, 
the  more  difficult  it  is  to  make  software 
changes.  Detecting  errors  in  program  func¬ 
tion,  caused  by  modification  to  program 
codes,  becomes  much  more  difficult  as  in¬ 
dividual  software  programs  are  joined  with 
each  other  through  a  series  of  integration 
tests.  Because  the  functional  implications 
of  even  small  program  change  can  be  vast, 
the  cost  of  making  them  increases  as  the 
development  process  proceeds.®  More  ro¬ 
bust  architectures  may  reduce  these  costs 
but  sufficient  time  for  design  and  test  must 
be  provided  to  avoid  later  problems.  Ex¬ 
perience  shows  that  a  lack  of  tight  software 
configuration  control  produces  extreme 
difficulty  in  both  testing  and  in-service  use. 

For  these  reasons,  any  change  in  functional 
requirements  must  be  assessed  carefully  to 
define  how  it  will  affect  on-going  develop¬ 
ment  activities. 

Configuration  Management,  and 
Documentation  of  System  Design 

Configuration  management  planning  and 
full  system  design  documentation  are  im¬ 
portant  for  any  acquisition  process.  In  an 
evolutionary  process,  careful  attention  to 
evolving  architecture  and  a  series  of  sys¬ 
tem  increments  are  of  paramount  impor¬ 
tance.  For  example,  managing  the  configu¬ 
ration  is  increasingly  complicated  and 
costly  when  both  past  and  present  evolu¬ 
tionary  increments  are  being  operated  and 
maintained  to  any  extent  with  separate 
personnel  skill  levels,  unique  tools  and 
technical  data  (including  training  and  re¬ 
pair  manuals  and  software),  different  re¬ 
pair  facilities  among  contractors  and  or¬ 
ganic  sites,  and  varied  provisioning  needs. 
The  technical  data  package  is  the  key  to 


Misconceptions  which  can  be  reinforced  by  programmers'  optimistic  response  to  management  suggestions. 

^  As  a  rule  of  thumb,  adding  a  small  additional  capability  through  software  change  when  the  development  cycle  is 
well  developed  will  likely  cost  ten  times  the  amount  such  a  change  would  cost  if  it  were  accommodated  at  the  start  of 
the  succeeding  developmental  increment. 
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disciplined  documentation.  It  is  essential 
that  documentation  be  comprehensive  and 
complete.  The  following  specific  activities 
impact  on  configuration  management. 

1.  Production  and  Installation:  When 
EA  processes  are  used  for  any  sort  of 
defense  systems,  primary  attention  is 
normally  focused  on  architecture,  re¬ 
quirements,  development,  integra¬ 
tion  and  evaluation.  When  hardware 
is  to  be  evolved,  the  time  between 
hardware  increments  may  be  long  (2 
to  3  years).  If  the  number  of  systems 
is  large,  the  installation  is  complex 
(such  as  in  aircraft  and  missiles),  or 
re-qualification  is  required,  then  the 
length  of  time  and  complexity  of  the 
system  integration  and  modification 
makes  configuration  management 
more  diffficutt. 

In  contrast,  many  large  and  complex 
systems  are  few  in  number  or  even 
"one-of-a-kind."  In  such  cases  the 
time  between  system  evolutionary 
increments  may  be  shortened  with 
only  small  impact  on  configuration 
management  and  installation.  Install¬ 
ing^  software  (exclusive  of  software 
integration  and  test  activities)  is  gen¬ 
erally  also  simpler:  it  involves  prima¬ 
rily  the  reading  of  digital  data  from  a 
magnetic  tape  or  disk  into  a 
computer's  internal  memory.  Thus, 
software  production  and  distribution 
cost  are  significantly  less  than  its 
development. 

When  many  systems  are  involved, 
provisions  for  interfacing  systems  of 
differing  capabilities  are  necessary 
and  more  care  is  required  in  configu¬ 
ration  management. 


2.  Software  Maintenance  and  Control: 

Maintenance  of  hardware  consists 
largely  of  four  kinds  of  actions  taken 
to: 

-  determine  whether  it  is  functioning 
properly, 

-  prevent  component  wear-out, 

-  correct  for  deviations  in  system  com¬ 
ponent  functional  characteristics 
("drift"),  and 

-  repair  or  replace  components  which 
are  badly  worn  or  have  failed. 

Software  and  hardware  maintenance  dif¬ 
fer  in  a  number  of  ways.  Since  software 
does  not  "drift",  wear  out,  burn  out  or 
break,  it  will  not  require  the  kind  of  main¬ 
tenance  described  above.  But  software  does 
malfunction:  most  often  when  the  system 
within  which  it  is  embedded  experiences 
conditions  which  produce  combinations  of 
software  inputs  that  had  not  been  consid¬ 
ered  during  the  testing  process.^ 

Because  software  maintenance  results  in 
change  to  software  functional  performance, 
it  is  imperative  to  observe  proper  configu¬ 
ration  management  procedures  during  the 
maintenance  process,  including  appropri¬ 
ate  revision  to  systems  documentation 
(technical  data  package).  This  must  be  done 
for  every  software  increment  that  is  ap¬ 
proved  for  routine  field  use. 

The  Acquisition  Strategy 

Special  emphasis  should  be  placed  on  de¬ 
velopment  of  an  acquisition  strategy  to 
provide  early  address  of  procurement  lead 
time  constraints. 


*’  Installation  includes  testing  to  ensure  software  was  installed  correctly. 

Software  test  data  are  normally  derived  from  consideration  of  system  operating  envelopes  within  specific  operat¬ 
ing  environments.  When  either  environment  changes,  or  system  operational  envelopes  are  exceeded,  software  func¬ 
tional  integrity  may  not  be  sustained. 
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The  EA  strategy  should  include  the  foUow- 
ing  elements  thought  necessary  to  ensure 
program  success: 

1.  An  Evolution  Plan:  An  outline  of  the 
projected  incremental  allocation  of  ca¬ 
pabilities  and  a  time  frame  for  their 
implementation.  Included  should  be 
a  time  phased  description  of  system 
interfaces,  a  guide  for  operational  test 
planning  and  a  basis  for  negotiating 
shared  development  and  support  re¬ 
sponsibilities. 

2.  An  Architectural  Plan:  A  descrip¬ 
tion  of  the  principles  on  which  the 
system  architecture  is  based  and  the 
kinds  of  change  that  architecture  can 
facilitate.  It  should  include  a  set  of 
guiding  principles  for  management, 
development  and  maintenance;  and 
an  outline  of  how  the  architecture  is 
expected  to  be  improved  in  the  fu¬ 
ture. 

3.  A  Technology  Road  Map:  A  sched¬ 
ule  for  the  availability  of  technology 
developments  which  relate  to  the  sys¬ 
tem  under  development.  This  should 
include  a  survey  of  COTS  products 
and  a  projected  schedule  for  matur¬ 
ing  emerging  technologies. 

4.  A  Funding  Profile  and  Contract 
Strategy:  A  summary  of  the  funding 
requirements  for  each  incremental 
development,  at  least  for  the  first  in¬ 
crement.  A  contract  strategy  should 
be  selected  which  tailors  existing  con¬ 
tract  practice  to  the  needs  and  struc¬ 
ture  of  the  evolving  program.  Early 
planning  will  also  provide  maximum 
opportunity  to  insure  effective  com¬ 
petition  practice. 

It  may  be  useful  to  include  a  two  phased 
approach  in  the  acquisition  plan  to  facili¬ 
tate  competitive  benefits. 


-  The  first  phase  would  involve  mul¬ 
tiple  awards  with  resulting  con¬ 
tracts  addressing  the  initial  (or  core) 
capabihty.  Potential  teaming  arrange¬ 
ments  would  be  indicated.  Concep¬ 
tual  segments  and  approaches  to  in¬ 
cremental  system  performance  im¬ 
provement  would  be  prepared  and 
system  specifications  prepared  at  this 
time.  In  some  cases,  the  plan  might 
even  provide  for  deliverable  demon¬ 
stration  models. 

-  The  second  phase  would  involve  se¬ 
lection  of  a  contractor  for  system  in¬ 
tegration.  Competition  would  be  pre¬ 
served  at  the  second  tier  for  each  in¬ 
dividual  system  increment  develop¬ 
ment. 

5.  A  Product  Assurance  Plan:  Solid 
product  assurance  planning  must 
link  all  aspects  and  phases  of  the  sys¬ 
tem  and  be  visible  at  decision  mile¬ 
stones.  Such  planning  should  recog¬ 
nize  specifically  that  in  an  evolution¬ 
ary  program,  the  developer's  respon¬ 
sibility  must  extend  through  user 
fielded  verification  which  might  en¬ 
tail  special  maintenance  or  warranty 
provisions. 

6.  Integrated  Logistic  Support  (ILS) 
Planning:  Support  planning  and 
analysis  serves  three  purposes: 

•  First,  it  determines  the  minimum  in¬ 
vestment  in  logistics  support  assets 
for  the  COTS  core  capability. 

•  Second,  it  ensures  that  the  evolving 
design  concurrently  pursues,  and 
meets,  both  technical  and  support 
performance  requirements. 

•  Third,  it  tailors  an  optimal  support 
program  to  sustain  and  measure 
performance  over  the  expected  ser¬ 
vice  life. 
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Early  support  planning  allows  for  more 
realistic  program  funding  and  scheduling 
profiles,  for  a  smooth  insertion  of  the  sys¬ 
tem  into  the  current  organic  support  infra¬ 
structure  (if  appropriate),  for  configuration 
control  of  the  various  (overlapping)  incre¬ 
ments,  and  for  the  feedback  needed  to  drive 
subsequent  evolutions. 

Although  additional  time  might  be  neces¬ 
sary  to  prepare  a  thorough,  comprehensive 
Acquisition  Strategy  at  the  outset,  doing  so 
will  tend  to  facilitate  a  smooth  transition 
from  phase  to  phase  (capability  to  capa¬ 
bility).  It  will  also  provide  for  much  greater 
accountability  and  increase  confidence  that 
the  desired  final  system  capability  can  be 
achieved. 

Tailoring  the  Acquisition  Approach 

Just  as  DoDI  5000.2  encourages  acquisition 
strategy  tailoring,  the  EA  approach  may 
also  be  tailored 

-  to  the  degree  of  user  and  developer 
knowledge  and  involvement  re¬ 
quired, 

-  to  requirements,  PPBS  needs,  or 
technological  uncertainties, 

-  to  the  degree  of  advanced  develop¬ 
ment  required,  and 

-  to  opportunities  for  use  of  off-the 
shelf  commercial  or  military  compo¬ 
nents. 

Figure  4. 1  displays  the  tailoring  concepts 
graphically. 

The  extent  of  user  and  developer  involve¬ 
ment  in  the  E  A  process  varies  according  to 
the  kind  of  system  being  acquired. 

Tailoring  Guidelines 

The  activities  and  relationships  required  to 
accomplish  EA  successfully  should  be  tai¬ 


lored  by  system  type  and  the  relative  im¬ 
portance  of  all  the  associated  factors. 

For  example,  where  heavy  user  involve¬ 
ment  is  indicated,  the  time  between  incre¬ 
ments  should  be  short  (6  months  to  1  year) 
to  provide  for  user  feedback.  When  there 
is  technological  imcertainty,  time  and  re¬ 
sources  for  advanced  development  may  be 
required.  Prototyping  at  user  facilities  may 
be  required  to  resolve  requirement  imcer- 
tainties.  There  is  more  potential  for  use  of 
non-developmental  items  (NDI)  and  COTS 
in  administrative  and  support  systems.  For 
sensor  and  weapon  systems,  most  of  the 
desired  system  capabilities  involve  tailor¬ 
ing  system  components  to  the  physical  and 
electromagnetic  operational  environ¬ 
ments.®  The  detailed  knowledge  and  expe¬ 
rience  required  to  do  that  are  likely  to  re¬ 
side  with  the  developer. 

For  headquarters-type  command  systems, 
the  major  capabilities  required  are  gener¬ 
ally  in  the  form  of  management  and  deci¬ 
sion  aids  and  must  be  tailored  to  the  com¬ 
mand  tactics,  procedures  and  operational 
style.  The  required  experience  and  disci¬ 
pline  to  define  capabilities  for  these  kinds 
of  systems  generally  are  found  in  the 
system's  ultimate  users. 

'"When  there  are  requirerments  uncertainties 
an  evolutionary  approach  is  generally  adopted 
because  it  has  to  be.  In  such  cases,  a  kind  of 
"design-and-try-out"  approach  must  be  taken 
to  both  the  need  and  the  approach  to  satisfying 
it.  Some  other  situations  which  are  likely  to 
drive  the  choice  of  an  EA  process  are: 

(a)  difficulty  in  stating  requirements  adequately 
at  the  beginning  of  true  like  programs, 

(b)  requirements  are  expected  to  change  fre¬ 
quently  over  the  life  of  the  program,  or 


*  Technically  such  capabilities  are  usually  provided  in  the  form  of  control  and  feedback  loops. 
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Support  Systems 


Headquarters  Systems 


Control  Systems 


Sensor/Weapon  Systems 


Figure  4-1.  Tailoring  the  Acquisition  Approach 
Factor  Relative  Importance  as  a  Function  of  the  Type  of  System  Being  Developed 
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ic)  users  cannot  specify  acceptability  criteria 
adequately  in  advance  due  to  their  subjective 
nature. 

"In  contrast,  when  there  are  technological  un¬ 
certainties,  an  evolutionary  approach  may  be 
adopted  for  any  one  of  a  number  of  reasons  even 
when  what  is  wanted  can  be  rather  precisely 
defined,  and  achieving  the  desired  end  objec¬ 
tive  can  be  more  objectively  measured. 

"When  requirements  uncertainty  indicates  an 
EA  approach,  the  program  may  involve  little 
or  no  advanced  development.^  In  contrast,  when 
technological  uncertainty  indicates  an  evolu¬ 
tionary  approach,  significant  amounts  of  ad¬ 
vanced  development  are  ordinarily  involved. 
Indeed,  the  evolutionary  strategy  has  been  de¬ 
rived  as  a  means  of  dealing  with  just  such  un¬ 
certainties  because  development  periods  in¬ 
volved  in  making  very  large  or  "revolutionary" 
jumps  at  the  limits  of  a  state-of-the-art  take  so 
long  and  are  so  risky  that  U.S.  readiness  is  be¬ 
ing  threatened. 

"While  it  is  highly  desirable  that  users  be  con¬ 
stantly  knowledgeable  about  programs  with 
technological  uncertainty — indeedplay  a  con¬ 
tinuous,  if  reactive  role  in  the  acquisition  of  any 
DoD  system  -  the  approach  for  these  programs 


does  not  require  user  acceptance  of  any  signifi¬ 
cant  responsibility  at  any  stage  of  the  acquisition 
cycle.  In  contrast,  for  programs  with  require¬ 
ments  uncertainty,  succeeding  blocks  of  work 
after  the  first  cannot  be  adequately  specified 
until  feedback  from  some  user  is  received  on  the 
usefylness  and  needed  modifications  to  prior 
blocks."^^ 

In  the  latter  case  the  time  between  incre¬ 
ments  must  be  kept  small  (6  months  to  1 
year)  and  it  may  be  desirable  for  the  user 
to  beta  test  prototypes  of  upcoming  incre¬ 
ments  to  assure  continuous  user  input  to 
the  evolving  development  process.  Where 
the  choice  of  an  evolutionary  approach  is 
driven  by  technological  uncertainy  or  fund¬ 
ing  and  schedule  considerations,  the  time 
between  increments  maybe  longer  and  tai¬ 
lored  to  expected  availability  of  new  tech¬ 
niques  or  funding. 

As  we  move  from  the  more  physically  con¬ 
strained,  high  technology  sensor  or 
weapon  systems  to  the  inventory  or  pay¬ 
roll  systems  which  support  the  administra¬ 
tive  needs  of  the  commands,  the  chances 
increase  for  the  exploitation  of  COTS  or 
NDI  components. 


’  For  example,  when  a  user  upgrades  his  capability  using  existing  commercial  or  military  materiel. 
The  quotation  is  taken  verbatim  from  the  AFCEA  Final  Report  referenced  in  Chapter  2,  Footnote  1. 
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GUIDELINES  FOR  PREPARING 
THE  ACQUISITION  STRATEGY  REPORT 
FOR  AN  EVOLUTIONARY  ACQUISITION 


Background 

A  survey^  of  6  OI  Program  Managers 
(PMs)  provided  insight  into  a  workable 
mechanism  for  achieving  authorization  to 
pursue  an  evolutionary  acquisition  (EA) 
strategy.  Each  manager  indicated  a  plan  to 
use  EA  as  the  strategy  in  the  program  Ac¬ 
quisition  Strategy  Report. 

What  follows  in  this  chapter  is  a  set  of 
Guidelines  for  preparing  the  Acquisition 
Strategy  Report.  Annotations  have  been 
added  to  indicate  references  to  the  E A  op¬ 
tion  permitted  in  the  various  policy  docu¬ 
ments  cited  in  Section  1. 

The  following  guidelines  are  keyed  to  ap¬ 
propriate  portions  of  the  acquisition  strat¬ 
egy  report.  Each  major  section  and  para¬ 
graph  of  the  report  is  discussed. 

Section  A:  Program  Structure 

1.0  Define  relationships  between  the  fol¬ 
lowing  items: 

1.1  Acquisition  Phases:  In  addition  to 
the  acquisition  phases,  describe  the  op¬ 
tions  set  forth  in  previous  Program 
Memoranda  and  delineate  EA  as  the 
option  the  acquisition  strategy  sup¬ 
ports. 


1.2  Decision  Milestones:  The  plan  must 
identify  decision  milestones  that  are 
necessary  to  permit  the  acquisition 
strategy  to  succeed.  The  plan  should 
address  all  the  technical,  business,  man¬ 
agement  and  other  significant  consid¬ 
erations  which  will  control  the  acquisi¬ 
tion.  An  Evolution  Plan  should  be  in¬ 
cluded  outlining  projected  incremental 
allocation  of  capabilities  and  a  time 
frame  for  their  implementation.  It 
should  present  a  time-phased  descrip¬ 
tion  of  sysem  interfaces,  a  guide  for  op¬ 
erational  testing,  and  a  basis  for  nego¬ 
tiating  shared  development  and  sup¬ 
port  activities.  Although  the  content  of 
each  plan  will  vary  depending  upon  the 
nature  and  circumstances  of  the  particu¬ 
lar  acquisition,  the  planner  should  fol¬ 
low  the  instructions  in  the  Federal  Ac¬ 
quisition  Regulation  (FAR)  Part  7,  Sub¬ 
part  7.1,  Paragraph  7.105  together  with 
any  specific  Service  implementing 
procedures. 

1.3  Solicitations:  Address  at  least  the  fol¬ 
lowing  steps  (and  any  others  which  are 
appropriate): 

•Acquisition  Plan  approval.  Indi¬ 
cate  when  plan  updates  will  be 
accomplished.  Updates  should  be 


^  See  the  discussion  within  the  Armed  Forces  Communications  and  Electronics  Association  report  ''Evolutionary 
Acquisition  Study"  dated  June  1993. 
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scheduled  to  coincide  with  the  De¬ 
fense  Acquisition  Board  (DAB)  re¬ 
views  and  transition  from  one  phase 
to  another  (i.e..  Demonstration  and 
Validation  to  Engineering  and  Manu¬ 
facturing  Development  [EMD]).  The 
plan  may  require  update  after  deliv¬ 
ery  of  one  or  more  evolutionary  in¬ 
crements. 

-Statement  of  Work 

-  Specifications 

-  Data  Requirements 

-  Completion  of  the  Acquisition  Pack¬ 
age  preparation 

-Purchase  Request  (indicating how 
the  evolutionary  option  will  be  im¬ 
plemented) 

-  If  other  than  full  and  open  competi¬ 
tion  is  required,  justification  and 
any  required  Determination  and 
Findings  approvals  should  be  indi- 
dicated  here.  (This  is  especially  true 
if  the  evolutionary  options  is  de¬ 
scribed). 

-  Issuance  of  a  s5mopsis 

-  Issuance  of  a  solicitation 

-  Beginning  and  completion  of  nego  - 
tiations 

-  Contract  preparation,  review,  and 
clearance. 

1 .4  Contract  Awards:  A  Funding  Profile 
and  Contract  Strategy  should  be  pro¬ 
vided.  A  summary  should  be  included 
of  the  funding  requirements  for  each 
increment  of  development;  at  least  for 
the  first  increment.  A  contract  strategy 
should  be  selected  which  tailors  exist¬ 
ing  contract  practice  to  the  needs  and 
structure  of  the  evolving  program. 

1.5  System  Engineering  design  reviews: 
For  EA,  reviews  should  be  tailored  for 
each  increment. 


1.6  Contract  deliveries  (Delivery  or 
Performance-period  requirements): 
Describe  the  basis  for  establishing  de¬ 
livery  or  performance  period  require¬ 
ments.  Explain  and  provide  reasons 
for  any  urgency  if  it  results  in 
concurrency  of  development  and  pro¬ 
duction  or  constitutes  justification  for 
not  providing  for  full  and  open  com¬ 
petition.  (See  page  4-2,  Section  5). 

1.7  Test  and  Evaluation  periods:  To  the 
extent  possible,  describe  the  test  pro¬ 
gram  for  both  contractor  and  Govern¬ 
ment  for  each  phase  of  the  acquisition. 
(See  page  4-1,  Section  2). 

1.8  Production  Releases:  A  detailed  re¬ 
lease  is  required  for  each  increment. 

1.9  Operational  Deployment  Objec¬ 
tives:  For  each  increment,  indicate  the 
date  of  approval  for  operational  use. 
If  waivers  are  requested,  describe  the 
need  for  them. 

2.0  Discuss: 

2.1  How  the  evolutionary  option  will 
be  implemented  including  any  degree 
of  concurrency  among  the  program 
technical  tasks  or  if  there  will  be  por¬ 
tions  of  the  program  in  separate  phases 
of  development.  The  need  for  long 
lead  items. 

2.2  Phase  transition  anticipated,  (See 
Section  4). 

3.0  List  quantities  of  items  to  be  procured 
for  each  increment  including  prototypes, 
engineering  development  models  and 
production  items.  It  is  especially  impor¬ 
tant  to  indicate  when  portions  of  the  core 
capability  will  be  available. 
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4.0  Summarize  the  program  on  a  single  dia¬ 
gram  indicating  how  the  E A  option  permits 
providing  deployable  capabilities  more 
rapidly  and  provides  feedback  for  adjust¬ 
ment  of  later  increments  (see  Figure  5.1). 

Section  B:  Acquisition  Approach 

1.0  Overview:  An  architectural  plan  should 
be  provided  which  describes  the  principles 
on  which  the  system  architecture  is  based. 
It  should  include  a  set  of  guiding  principles 
for  management,  development  and  main¬ 
tenance  of  the  architecture  and  an  outline 
of  how  the  architecture  is  expected  to  be 
improved  in  the  future.  In  addition,  a  Tech¬ 
nology  Road  Map  should  be  provided 
which  projects  availability  of  technological 
development,  includes  a  survey  of  com¬ 
mercial-off-the-shelf  (COTS)  products,  and 
a  projected  schedule  for  emerging  tech¬ 
nologies. 

1.1  Discuss  basic  acquisition  strategy  to 
include  transition  of  critical  technolo¬ 
gies  in  technology  demonstrations  in 
the  context  of  operational  requirements 
and  management  approach  for: 

1.1.1  Prototypes  of  elements  of  an 
initial  core  capability  and  elements 
which  will  be  added  to  the  core  as 
they  become  available. 

1.1.2  Engineering  Development 
Models  (especially  simulations) 
which  validate  the  evolutionary 
development  of  core  capability  com¬ 
ponents  and  which  show  that  sys¬ 
tem  integration  will  be  successful. 

1.1.3  Plans  for  reducing  the  risk  in¬ 
herent  in  the  development  and  how 
the  choice  of  an  evolutionary  option 
will  aid  in  risk  reduction. 

1.1.4  Non-Development  Items 
(NDI).  Identify  the  NDIs  which 


could  help  shorten  the  time  required 
to  deploy  core  and  subsequent  add¬ 
on  capabilities.  Indicate  the  efforts 
(planned  or  under  way)  which  will 
identify  NDIs  with  emphasis  on 
COTS  items.  Describe  what  arrange¬ 
ments  have  or  will  be  made  for  lo¬ 
gistics  support  of  the  NDI  or  COTS 
for  its  duration. 

1.1.5  How  the  Evolutionary  option 
will  be  implemented.  Identify  how 
it  will  provide  for  more  rapid  de¬ 
ployment  of  capabilities  which  sat¬ 
isfy  operational  requirements  while 
facilitating  use  of  the  most  advanced 
technology. 

1.1.6  Information  on  planned  prod¬ 
uct  improvements  which  are  in¬ 
cluded  within  the  program  and  how 
the  EA  process  will  facilitate  their 
achievement  with  less  risk  than 
would  otherwise  be  possible. 

1.2  Discuss  applicable  Government 
management  responsibilities  vis-a-vis 
the  contractors,  specifically  with  regard 
to: 

1.2.1  System  integration:  Describe 
how  the  Government  will  perform 
that  role  if  it  is  reserved  to  Govern¬ 
ment. 

1.2.2  Government  support  of  the 
system.  Explain  how  the  govern¬ 
ment  and  the  contractor  will  sup¬ 
port  the  system  initially,  and 
throughout  the  life-cycle.  Include 
consideration  of  government  main¬ 
tenance  and  servicing  as  the  system 
evolves  and  the  methodology  for 
insuring  distribution  of  commercial 
products  as  required  during  the  sys¬ 
tem  operating  life.  An  Integrated 
Logistic  Plan  (ILS)  Plan  should  be 
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provided.  As  with  conventional  ap¬ 
proaches,  ILS  is  critical  in  EA.  The 
plan  should  insure  that  support  re¬ 
sources  and  services  are  in  place  at 
the  time  the  core  (and  all  succeed¬ 
ing  increments)  is  delivered . 

1.2.3  Government  Furnished  Equip¬ 
ment  (GEE).  Indicate  any  equipment 
or  property  to  be  furnished  to  con¬ 
tractors  including  materials,  facili¬ 
ties  or  commercial  purchases.  Dis¬ 
cuss  how  schedule  requirements 
will  be  met  and  how  availability  will 
be  insured  so  that  the  system  capa¬ 
bilities  can  evolve  as  planned 

1.2.4  Government  Furnished  Infor¬ 
mation.  Discuss  any  information  to 
be  provided  to  prospective  offerers 
and  to  contractors  after  contract 
award.  Indicate  specific  manuals, 
drawings,  test  data,  or  other 
Government  generated  or  owned 
information  involved  in  develop¬ 
ment  and  fielding  each  increment  of 
system  capability. 

1.3  Discuss  applicable  contractor  man¬ 
agement  responsibilities  during  the  life 
of  the  contract  and  during  succeeding 
support  period.  Discuss  product  assur¬ 
ance  planning.  Solid  product  assurance 
plarming  must  include  all  aspects  and 
phases  of  the  system  and  be  visible  at 
decision  milestones.  Such  planning 
should  recognize  specifically  that  in  an 
E A  program,  the  developer's  responsi¬ 
bility  must  extend  through  deployment 
and  operations,  which  might  entail  spe¬ 
cial  maintenance  or  warranty  provi¬ 
sions.  Specific  areas  to  be  addressed  are: 

1.3.1  Systems  integration  tasks  per¬ 
formed  by  the  contractor,  especially 
items  which  are  critical  to  the  initial 
system  capability.  These  must  be 


tested  individually  and  as  expand¬ 
ing  aggregations  of  components. 

1.3.2  Contractor  furnished  equip¬ 
ment  to  be  provided  under  the  con¬ 
tract  and  for  support  of  the  initially 
fielded  capability. 

1.3.3  Contractor  furnished  data  and 
information  necessary  to  the  gov¬ 
ernment  management  activity  and 
necessary  to  a  using  agency. 

1.4  References  for  Acquisition  Ap¬ 
proach:  Federal  Acquisition  Regulation 
(FAR)  and  Defense  Federal  Acquisition 
Regulation  Supplement  (DEARS)  para¬ 
graphs  which  are  to  be  related  to  para¬ 
graphs  in  this  portion  of  the  acquisition 
plan: 


Part  7,  EARS  Paragraphs 

subpart  7.1  7. 105(b)(6),  (b)(12), 

(b)(13),  (b)(14) 


Part  207,  DEARS 

subpart  207.1  Paragraph 

207. 105(b)(6), 
(b)(12) 


2.0  Streamlining 


2.1  Discuss  how  EA  permits  process 
streamlining  through  combining  work 
which  otherwise  would  have  been  per¬ 
formed  later  in  program  development. 
This  can  result  in  combining  program 
phases  or  eliminating  some  of  them 
entirely.  Also  discuss  how  EA  permits 
use  of  consolidated,  simplified  program 
documentation  and  streamlined  con¬ 
tractual  requirements. 

2.2  Identify  the  need  for  any  waivers  or 
deviations. 
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2.3  Discuss  any  application  of  Defense 
Enterprise  Programs  or  milestone  au¬ 
thorizations. 

2.4  Indicate  how  the  process  better  ac¬ 
commodates  legislative  direction;  spe¬ 
cifically,  how  use  of  COTS  and  NDI  can 
assist  in  "competitive  prototyping."  If 
live  fire  testing  is  required  for  the  pro¬ 
gram,  indicate  how  an  EA  process  can 
help  achieve  it. 

2.5  FAR  and  DEARS  regulations  to  be 
related  to  these  paragraphs  in  the  ac¬ 
quisition  plan  are: 


Part  7, 
subpart  7.1 


Part  207, 
subpart  207.1 


EARS 

Paragraph 

7.105(a)(8) 

DEARS 

Paragraph 

207.105(a)(8) 


3.0  Sources 

3.1  Indicate  sources  of  supplies  and  ser¬ 
vices.  Consider  needs  for  the  entire  pro¬ 
gram.  If  the  acquisition  (or  any  part  of 
it)  is  for  commercial-type  products  (or 
if  commercial-type  products  are  a  ma¬ 
jor  portion  of  the  materials  included  in 
the  system)  address  the  methodology 
to  be  used  in  determining  availability 
and  sources  of  continuing  supply.  If  no 
make  survey  is  to  be  conducted,  explain 
why.  Also  discuss  energy  conservation 
measures,  standardization  concepts 
and  industrial  readiness. 

3.2  Include  consideration  of  small  busi¬ 
ness  or  small  disadvantaged  business; 
labor  surplus  areas  or  the  need  to  cre¬ 
ate  or  preserve  domestic  sources  of  pro¬ 
gram  systems  components.  Discuss 
how  the  acquisition  strategy  contributes 
to  Industrial  Preparedness  Objectives 


and  to  Surge  and  Mobilization  objec¬ 
tives  or  contingency  support  and  recon¬ 
stitution;  include  any  specific  plan  ei¬ 
ther  by  text  or  reference.  If  no  plan  is 
available,  summarize  the  analysis  of 
impact  details  of  these  objectives  on  se¬ 
lection  of  EA. 

3.3.  For  Acquisition  Category  I  pro¬ 
grams,  include  analysis  and  assessment 
of  how  the  Defense  Industrial  Base  is¬ 
sues  (See  Title  10  United  States  Code 
[USC]  Section  2502:  Policies  relating  to 
defense  industrial  base)  impact  on  sys¬ 
tem  development,  the  capability  to  pro¬ 
duce  and  maintain  developed  systems 
and  the  quality  of  those  systems.  Also 
discuss  system  support  and  how  reli¬ 
ability  and  maintainability  are  en¬ 
hanced  by  selecting  EA.  Indicate  how 
EA  can  help  assure  extensive  use  of 
warranties  for  COTS  and  NDI.  Discuss 
how  competitive  development  can  be 
facilitated  by  competing  the  COTS  and 
NDI  elements  of  the  evolving  system. 
Include  any  impact  on  standardization 
considerations  (Type  Classification): 
specifically,  how  to  make  future  equip¬ 
ment  purchases  from  the  same  sources. 
Indicate  how  competition  can  help  in¬ 
sure  at  least  two  production  sources  for 
COTS  and  NDI  production  items. 


3.4.  The  FARs  related  to  these  para¬ 
graphs  in  the  acquisition  plan  are: 

Part  7,  FARS 

subpart  7.1  Paragraph 

7. 105(b)(1),  7.105 
(b)(17),  7.106(b) 

Part  207,  DEARS 

subpart  207.1  Paragraph 

207.105(b)(17) 

207. 106(b)(1)(A), 
207. 106(b)(1)(B) 
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4.0  Competition 


5.0  Contract  Types 


4.1  Explain  how  EA  will  maximize  com¬ 
petition  throughout  each  phase  of  the 
entire  life-cycle.  Discuss  competitive 
and  noncompetitive  aspects  of  each 
phase  and  describe  how  competition 
wiU  be  sought,  promoted  and  sustained 
for  the  system,  all  subsystems,  major 
components  and  spare  parts.  Specifi¬ 
cally,  discuss  results  of  breakout  re¬ 
views  and  breakout  strategy  relative  to 
each  system  element  and  identify  key 
components  and  logistics  milestones 
(e.g.,  technical  data  delivery  schedule 
conferences)  which  affect  competition. 
If  continuing  contracts  for  services  are 
required,  discuss  how  they  will  be 
achieved. 


4.2  Discuss  the  use  of  repurchased  data 
to  increase  competition.  Include  esti¬ 
mated  costs  and  funding  availability  to 
repurchase  data.  Discuss  contractual 
approaches  for  acquiring  such  data  and 
how  it  will  be  used.  Detail  technical 
data  rights  and  patent  considerations  . 


4.3  Discuss  the  results  of  detailed  com¬ 
ponents  breakout  reviews  for  major 
components  and  subsystems  and 
whether  such  items  should  be  Govern¬ 
ment  Furnished  Equipment  (GEE). 
Present  an  analysis  of  reviews  in  accor¬ 
dance  with  DEARS  Appendix  D  - 
Component  Breakout. 

4.4  The  EARS  to  be  related  to  these  para¬ 
graphs  in  the  acquisition  plan  are: 

Part  7,  EARS 

subpart  7.1  Paragraph 

7.105(b)(2), 

(b)(12) 

Part  207,  DEARS 

subpart  207.1  Paragraph 

207.105(b)(2) 


5.1  For  each  phase,  discuss  the  types  of 
contracts  anticipated.  Include  in  the  dis¬ 
cussion  considerations  of  multi-year 
contracting,  any  special  clauses  or  so¬ 
licitation  provisions,  and  whether 
sealed  bidding  (possibly  for  COTS  and 
NDI  items)  or  negotiation  methodology 
is  applicable  for  the  system  and  its 
components. 

5.2  Include  discussion  of  risk  and  pro¬ 
vide  risk  assessment  information  which 
supports  choice  of  the  type  of  contract. 
Include  a  discussion  of  risk-sharing  by 
Government  and  contractors. 

5.3  Identify  the  incentive  structure.  Spe¬ 
cifically,  in  connection  with  industrial 
preparedness  planning,  industrial  base, 
COTS  and  NDI  considerations,  provide 
a  rationale  for  incentives  to  invest  in 
capital  facilities,  capital  equipment,  and 
advanced  technology. 

5.4  Address  all  existing  or  contemplated 
deviations  or  waivers  particularly  any 
which  result  from  selection  of  an  E  A  op¬ 
tion. 

5.5.  Discuss  fixed  price  development 
contracts  requiring  Defense  Acquisition 
Executive  approval:  specifically,  con¬ 
tracts  in  excess  of  $25  million  (or  lower 
amount  if  prescribed  by  law),  or  fixed 
price  contracts  for  lead  ships.  Indicate 
whether  waivers  are  required  for  any 
phase  of  the  fixed  price  contract. 

5.6.  The  FARs  related  to  those  para¬ 
graphs  in  the  acquisition  plan  are: 

Part  7,  FARS 

subpart  7.1  Paragraph 

7.105(b)(4) 
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Part  207,  DFARS 

subpart  207.1  Paragraph 

207.105(b)(17)(A) 

6.0  Major  Trade-offs 

Identify  major  trade-off  decisions,  espe¬ 
cially  any  trade-offs  between  cost,  sched¬ 
ule  and  performance.  Identify  major  trade¬ 
off  decisions  to  be  retained  by  milestone  de¬ 
cision  authority.  Any  trade-off  to  be  in¬ 
cluded  in  formal  solicitations  must  be  iden¬ 
tified  and  discussed  in  depth. 

Evolutionary  Acquisition 
Summary 

Figure  5.1  shows  how  the  EA  process  pro¬ 
ceeds  with  weapon  development.  The 
development  time  is  divided  into  a  period 


during  which  an  initial  capability  is  devel¬ 
oped  and  deployed;  and  periods  within 
which  incremental  capabilities  are  devel¬ 
oped  and  deployed.  Note  that  there  is  im- 
certainty  about  the  exact  dates  of  initial  and 
subsequent  capability  delivery.  These  kinds 
of  imcertainties  are  also  reflected  in  costs 
projected  for  any  capability 

Sources  of  Additional  Information 

The  Defense  Systems  Management  College 
(DSMC)  plans  to  continue  its  support  of  the 
Joint  Logistics  Commanders  Evolutionary 
Acquisition  initiatives.  In  that  regard,  if 
there  are  questions  about  these  guidelines 
or  their  implementation,  discussion  with 
DSMC's  Systems  Engineering  Department 
is  encouraged. 
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Figure  5-1.  Evolutionary  Acquisition 
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